What this PR does

Adds performance benchmarks for the compliance scanner — the innermost loop of every ckb audit compliance run — which had zero benchmark coverage. Also commits a reproducible baseline and documents every efficiency issue found during the investigation.

Files changed:

• internal/compliance/scanner_bench_test.go — 10 benchmark functions
• testdata/benchmarks/compliance_baseline.txt — committed 5-run baseline (Apple M4 Pro, arm64)

Architecture context

During ckb audit compliance, RunAudit fans out up to 131 checks in parallel (capped at 32 workers). The per-line call chain during a PII scan is:

RunAudit (parallel, up to 32 workers)
  └─ check.Run(scope)              — 131 checks, many open all files independently
       └─ PIIScanner.ScanFiles()   — opens every source file with os.Open
            └─ scanFile (per file)
                 └─ extractContainer(line)       — 7 compiled regexes, every line
                 └─ extractIdentifiers(line)     — regex match + map alloc, every line
                      └─ normalizeIdentifier(id) — camelCase→snake_case, per identifier
                           └─ matchPII(norm)     — map lookup + O(n) suffix scan
                                └─ isNonPIIIdentifier(norm) — 46-entry linear scan

On a large repo this chain runs tens of millions of times across the check fan-out.

Benchmark results (Apple M4 Pro, arm64, -count=5)

Individual hot paths

On the zeros: matchPII and isNonPIIIdentifier allocate nothing in their inner paths. Zero is correct — map lookups and string comparisons stay on the stack.

Pipeline scale (single file)

Throughput is flat ~8.3 MB/s regardless of file size — the work is strictly O(lines). But 14 allocs/line is constant. Every line allocates regardless of content.

File-set scale (full audit simulation)

Perfectly linear — no amortization. On a 20k-file monorepo with all frameworks enabled, multiple PII-checking frameworks (GDPR, HIPAA, CCPA, ISO27701) each invoke the PII scanner independently, so the real allocation count is a multiple of these figures.

Pattern count scaling

Exactly O(n). Every miss touches every pattern. Custom patterns from .ckb/config.json degrade all non-matching identifiers proportionally.

Efficiency issues found — ranked by impact

1. regexp.MustCompile inside the per-line inner loop — CRITICAL

Three safety-framework checks compile a new regex on every line of every file:

internal/compliance/iec61508/structural.go:118
internal/compliance/iso26262/asil_checks.go:142
internal/compliance/do178c/structural.go:187

All three have the identical pattern:

for _, file := range scope.Files {
    for i, line := range lines {
        if currentFunc != "" && lineNum > funcStartLine {
            callPattern := regexp.MustCompile(`\b` + regexp.QuoteMeta(currentFunc) + `\s*\(`)
            // ^^^^ compiled per line, per file ^^^^
            if callPattern.MatchString(line) { ...

regexp.MustCompile parses and compiles the regex each call. For a 10k-line file with 500 functions, this compiles 10k–500k regexes per check invocation. The pattern only changes when currentFunc changes (at a new function boundary), so it should be compiled once per detected function, not once per line.

Fix: move the compile outside the line loop, keyed on currentFunc:

var callPattern *regexp.Regexp
var compiledFor string

for i, line := range lines {
    if m := funcDefPattern.FindStringSubmatch(line); len(m) > 1 {
        currentFunc = m[1]
        callPattern = regexp.MustCompile(`\b` + regexp.QuoteMeta(currentFunc) + `\s*\(`)
        compiledFor = currentFunc
        _ = compiledFor
    }
    if callPattern != nil {
        callPattern.MatchString(line)
    }

Or even simpler: use strings.Contains(line, currentFunc+"(") — the regex only needs to match a word boundary and \s*(, which strings.Contains can approximate with a quick check before a regex fallback.

2. 18 independent NewPIIScanner + ScanFiles calls per audit — HIGH

Every PII-related check creates its own scanner and walks every source file:

gdpr/pii.go           — 3 calls (pii-detection, pii-in-logs, pii-in-errors)
gdpr/retention.go     — 4 calls (no-retention-policy, no-deletion-endpoint,
                                  missing-consent, and a 4th check)
gdpr/crypto.go        — 1 call
hipaa/phi_detection.go — 2 calls
hipaa/access_control.go — 2 calls
iso27701/processing.go — 1 call
iso27701/rights.go    — 4 calls (one per rights check)
iso27001/leakage.go   — 1 call

Each ScanFiles call opens every .go/.ts/.py/... file in the repo with os.Open, reads it line by line, and runs the full normalize+match pipeline. A 5k-file repo scanned 18 times = 90k redundant file opens with 90k redundant pipeline passes.

Since all 18 calls use the same scope.Config.PIIFieldPatterns, the result is identical every time. The ScanScope is shared across all checks but has no result cache.

Fix: compute PII fields once, store on ScanScope:

type ScanScope struct {
    // ... existing fields ...
    piiOnce   sync.Once
    piiFields []PIIField
    piiErr    error
}

func (s *ScanScope) GetPIIFields(ctx context.Context) ([]PIIField, error) {
    s.piiOnce.Do(func() {
        scanner := NewPIIScanner(s.Config.PIIFieldPatterns)
        s.piiFields, s.piiErr = scanner.ScanFiles(ctx, s)
    })
    return s.piiFields, s.piiErr
}

Expected reduction: 17 of 18 full file scans eliminated. On a 5k-file audit this is the difference between 5.6s × 18 and 5.6s × 1 for PII scanning alone.

3. gdpr/retention.go reads files twice per check — HIGH

noRetentionPolicyCheck.Run (retention.go:22) calls piiScanner.ScanFiles to find PII fields (opens all files once), then immediately calls os.ReadFile on every file again to scan for retention indicators (line 49):

piiScanner := compliance.NewPIIScanner(scope.Config.PIIFieldPatterns)
piiFields, _ := piiScanner.ScanFiles(ctx, scope)     // opens all files
...
for _, file := range scope.Files {
    content, err := os.ReadFile(filepath.Join(..., file))  // opens all files again
    lower := strings.ToLower(string(content))              // copies entire file to lowercase

strings.ToLower(string(content)) on large files allocates a full copy of the file contents. Three more checks in retention.go repeat the same double-open pattern (lines 156, 215, 384).

Fix: check for retention indicators during the initial PII scan pass (they can share the same line-by-line iteration), or cache file contents on ScanScope for the first read.

4. nonPIISuffixes slice allocated on every isNonPIIIdentifier call — MEDIUM

// scanner.go:283 — inside the function body
func isNonPIIIdentifier(normalized string) bool {
    ...
    nonPIISuffixes := []string{   // ← allocated every call
        "file_name", "filename", "func_name", "function_name",
        // ... 46 entries total
    }
    for _, suffix := range nonPIISuffixes {
        if normalized == suffix || strings.HasSuffix(normalized, "_"+suffix) {

A 46-element string slice is allocated on the heap every time this function is called. isNonPIIIdentifier is called from matchPII for every identifier that hits the name-matching path — potentially millions of times per audit.

Additionally, iterating 46 suffixes linearly when most calls return false after the full scan is O(46) per call. This is measurable in the benchmark at 197 ns/op, but the allocation is the worse issue.

Fix: move to a package-level map[string]bool built at init time:

var nonPIISuffixSet = func() map[string]bool {
    suffixes := []string{"file_name", "filename", ...}
    m := make(map[string]bool, len(suffixes))
    for _, s := range suffixes {
        m[s] = true
    }
    return m
}()

Then the check becomes O(1) with no allocation: return nonPIISuffixSet[normalized] (with a suffix-split for the HasSuffix case).

5. extractIdentifiers allocates a fresh map[string]bool per line — MEDIUM

// scanner.go:375
func extractIdentifiers(line string) []string {
    seen := make(map[string]bool, len(matches))  // ← new allocation every line

At 14 allocs/line and ~6,000 allocs for 500 lines, this map is the dominant allocation source. For a 5k-file audit it produces ~18M allocations just from this map.

Fix: pass a map[string]bool in from the caller (created once per file, cleared between lines):

// In scanFile, create once:
seen := make(map[string]bool, 32)

// Each line:
for k := range seen { delete(seen, k) }  // clear
identifiers := extractIdentifiersInto(line, seen)

Go's map-clear idiom (for k := range m { delete(m, k) }) reuses the underlying hash table memory without resizing. This would cut 18M allocs to ~5k (one per file) for the same audit.

6. matchPII suffix scan is O(n_patterns) — MEDIUM

// scanner.go:256
for _, p := range s.patterns {
    if len(p.Pattern) > 4 && strings.HasSuffix(normalized, "_"+p.Pattern) {

Every identifier that doesn't exactly match (the common case) triggers a linear scan across all patterns. Already measured: 1.13µs for the default ~80 patterns, scaling to 5.27µs at 500. With 18 independent scanner instances, custom patterns degrade all 18 passes.

Fix: at NewPIIScanner construction time, build a suffix → pattern index:

type PIIScanner struct {
    ...
    suffixIndex map[string]PIIPattern  // last snake_case word → pattern
}

When checking user_email_address, extract the last word (address) and look it up directly. O(1) instead of O(n_patterns).

7. normalizeIdentifier rune allocations — LOW

Four heap allocations per call: []rune conversion, result []rune append, string(result) conversion, and the strings.ReplaceAll loop for __ collapsing. The loop is bounded (SCREAMING_SNAKE identifiers can have consecutive underscores) but allocates a new string on each iteration.

The 138 ns/op baseline is acceptable for typical identifiers. The 650 ns/op for long (60-char) identifiers is where the rune slice capacity grows. Not a priority fix unless normalizeIdentifier is called on very long synthetic identifiers, but worth noting for the suffix-index approach above (which would call normalizeIdentifier less often).

8. bufio.Scanner default 64 KB line limit — LOW

All file scanning (scanner.go, ScanFileLines) uses bufio.NewScanner(f) with the default 64 KB max token size. This causes silent truncation on lines longer than 64 KB — possible in minified JS, generated protobuf, or large raw string literals. Not a performance issue but a correctness risk on generated code.

Summary table

How to compare after optimizations

# After making changes:
go test -bench=. -benchmem -count=6 ./internal/compliance/... > /tmp/after.txt
benchstat testdata/benchmarks/compliance_baseline.txt /tmp/after.txt

The BenchmarkAuditFileSet benchmarks are the best signal for the high-impact fixes — they will show the improvement from fix #2 (PII scan deduplication) most clearly, since they simulate the multi-file pass that dominates real audit time.

Test plan

• go test -run='^$' -bench='^$' ./internal/compliance/... — compile check passes
• Full benchmark run completes without errors (84s for -count=5 on M4 Pro)
• Baseline committed and readable by benchstat
• Re-run baseline locally if your machine differs from arm64